Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

do not optimize docusaurus build #880

Merged
merged 2 commits into from
May 24, 2023
Merged

do not optimize docusaurus build #880

merged 2 commits into from
May 24, 2023

Conversation

pgrange
Copy link
Contributor

@pgrange pgrange commented May 17, 2023

The Documentation step was taking several minutes to optimize a web-site we will, most of the time, never publish. And, also, it was doing it twice sometimes.

So we do not generate documentation twice anymore. Also, we only generate optimized documentation for branch master and release. For all the other branches, we keep building the docusaurus stuff but only for sanity check so we don't optimize and we don't upload the artifact either.

To check that this P.R. did not break with the Publish Docs workflow, one can check this run which contains an artifact that you can download to check locally (spoiler alert: it still works): https://github.com/input-output-hk/hydra/actions/runs/5047620832

  • saves around 5 minutes
  • Introduces a new TODO to remove backward compatibility C.I. code in the future

@github-actions
Copy link

github-actions bot commented May 17, 2023

Test Results

318 tests  +11   312 ✔️ +11   21m 49s ⏱️ +12s
108 suites +  4       6 💤 ±  0 
    6 files   +  1       0 ±  0 

Results for commit 8c18875. ± Comparison against base commit 2365ffd.

♻️ This comment has been updated with latest results.

@pgrange pgrange requested a review from ffakenz May 17, 2023 16:01
@pgrange
Copy link
Contributor Author

pgrange commented May 17, 2023

@ffakenz could you double check what I changed here?

I'm considering that, either we're on master or not so I don't generate documentation twice, once for stable and once for unstable.

But, honestly, I have no idea what impact it may have in the way we publish our doc. Did I break something?

@pgrange pgrange self-assigned this May 17, 2023
@github-actions
Copy link

github-actions bot commented May 17, 2023

Transactions Costs

Sizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using arbitrary values and results are not fully deterministic and comparable to previous runs.

Metadata
Generated at 2023-05-24 09:51:46.50305403 UTC
Max. memory units 14000000
Max. CPU units 10000000000
Max. tx size (kB) 16384

Script summary

Name Hash Size (Bytes)
νInitial e5cc20df4a2216e706b3d00b59fbb15a7cf12dbd28d271d4a8cf6d04 4336
νCommit 47c102d5f95a0648b4065f2b8bff59d3e34536a82ee7b0d42df73123 2124
νHead 9fe3a5c4d826f9475368e1e24c15bf22f4df19893cce2689d3c0564a 9492
μHead 7bec671467e923281c92e94257931913be106e217270a7b97076cb9b* 4148
  • The minting policy hash is only usable for comparison. As the script is parameterized, the actual script is unique per Head.

Cost of Init Transaction

Parties Tx size % max Mem % max CPU Min fee ₳
1 4741 12.92 5.06 0.50
2 4944 15.24 5.93 0.53
3 5151 19.82 7.74 0.59
5 5562 24.34 9.44 0.66
10 6586 36.52 14.04 0.84
37 12124 97.41 36.90 1.74

Cost of Commit Transaction

Currently only one UTxO per commit allowed (this is about to change soon)

UTxO Tx size % max Mem % max CPU Min fee ₳
1 603 15.29 5.93 0.34

Cost of CollectCom Transaction

Parties UTxO (bytes) Tx size % max Mem % max CPU Min fee ₳
1 57 825 27.72 10.80 0.49
2 114 1139 43.16 16.96 0.67
3 171 1463 60.62 23.98 0.88
4 227 1792 81.88 32.54 1.13

Cost of Close Transaction

Parties Tx size % max Mem % max CPU Min fee ₳
1 639 18.88 8.43 0.39
2 805 19.98 9.56 0.42
3 969 21.37 10.82 0.44
5 1299 24.16 13.33 0.50
10 2124 31.13 19.62 0.64
50 8725 87.17 69.99 1.74

Cost of Contest Transaction

Parties Tx size % max Mem % max CPU Min fee ₳
1 675 24.77 10.64 0.46
2 842 26.06 11.84 0.48
3 995 28.20 13.38 0.52
5 1335 31.63 16.12 0.58
10 2161 40.20 22.97 0.74
44 7772 98.03 69.37 1.78

Cost of Abort Transaction

Some variation because of random mixture of still initial and already committed outputs.

Parties Tx size % max Mem % max CPU Min fee ₳
1 4857 22.19 9.33 0.61
2 5183 36.25 15.44 0.78
3 5504 53.24 22.87 0.99
4 5828 72.83 31.46 1.22
5 6149 95.12 41.22 1.49

Cost of FanOut Transaction

Involves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.

Parties UTxO UTxO (bytes) Tx size % max Mem % max CPU Min fee ₳
5 0 0 4764 8.67 3.57 0.46
5 1 57 4800 10.06 4.39 0.47
5 5 285 4944 15.64 7.69 0.55
5 10 566 5122 22.61 11.82 0.64
5 20 1140 5485 36.57 20.08 0.83
5 30 1709 5846 50.53 28.34 1.02
5 40 2275 6197 64.49 36.60 1.21
5 50 2845 6561 78.46 44.87 1.40
5 65 3701 7104 99.42 57.28 1.68

@ch1bo ch1bo self-requested a review May 22, 2023 09:42
@pgrange pgrange force-pushed the doc_faster branch 5 times, most recently from a472ca1 to 67905d3 Compare May 22, 2023 16:01
@pgrange pgrange marked this pull request as ready for review May 22, 2023 16:01
@pgrange pgrange changed the title WIP: do not optimize docusaurus build do not optimize docusaurus build May 22, 2023
Copy link
Collaborator

@ch1bo ch1bo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The premise of this work is very much what I thought we fix about this workflow:

  • keep sanity checking of docs separate from actually creating the website, effectively using the fastest, complete build for CI
  • move the building of the website into the https://github.com/input-output-hk/hydra/actions/workflows/publish-docs.yaml workflow
    • not using artifacts, but just building it twice whenever we need it built
    • that is, push on master and push on release branches for example

Instead of trying to optimize a conceptionally fragile workflow, I would suggest to move to a more robust approach first and by that, eliminate slow CI by design?

.github/workflows/ci.yaml Show resolved Hide resolved
pgrange added 2 commits May 24, 2023 11:36
We do not optimize docusaurus build when not on master or release.
We only want to sanity chack the doc and the links but do not plan
to ever publish this doc. Not optimizing saves minutes.

In case we're building for master or release, then, we optimize.

Also, we did not need both stable/unstable versions for master so
we only build the doc once.
@pgrange pgrange merged commit c0473a4 into master May 24, 2023
@pgrange pgrange deleted the doc_faster branch May 24, 2023 10:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants